This change currently introduces a regression:
I tested the change and printed out the old and new values for comparison. Turns out that the new method call always writes 0 to the passed buffer and, in particular, the method call always returns false, such that the size is not taken into account.
One example consequence is that if I set a high OS cursor size (like 10), the cursor is still 1 pixel wide. For example, in a console window it used to look like this (with OS cursor size 10):

And now it looks like this:

Note that the documentation of the used method states that it cannot be called with SPI_GETCARETWIDTH as done here but will always return 0 in that case: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfofordpi#remarks

The goal should be to make sure this doesn't cause any regression.

If I understand correctly, there was actually a bug that this PR now resolves: before, the cursor width was not scaled according to the monitor. So, e.g., a Windows setting of cursor size 10 would have resulted in pixel-width 10 for the cursor on both a 100% and 150% monitor whereas now on the 150% monitor the width will be 15 pixels.
So would be good to have that properly documented in the commit and PR messages.